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EFFICIENT IMPLEMENTATION OF TYPED 
VIEW HIERARCHIES FOR ORDBMS 

FIELD OF THE INVENTION 

The present invention relates to relational database man- 5 
agement systems, and more particularly to typed view 
hierarchies for an object-relational database management 
system (ORDBMS). * 

BACKGROUND OF THE INVENTION 

More and more software applications are being written in 
object oriented languages such as C++ or Java. Over the past 
few years, object oriented database management systems 
(OODBMS) have been developed to serve this need. 
However, known object oriented database management sys- 
tems do not provide the many features and the scalability of 
known is relational database management systems 
(RDBMS). In response to this need, vendors of relational 
database management systems have attempted to extend the 
functionality of their RDBMS products to capture the object 2Q 
oriented market. The result is an object-relational database 
management system (ORDBMS) which provides the appli- 
cation program with an object oriented view of its data while 
maintaining a relational treatment for queries and update 
operations. 25 

The foundation of a relational database management 
system or RDBMS is a set of tables which hold the actual 
relational data. On top of the tables, the RDBMS provides a 
level of encapsulation known as "views". The purpose of the 
views is to provide different "views" on the same set of data 30 
for different groups of clients. The different views protect 
both the data from being seen by unauthorized groups and 
the clients from being overwhelmed by information that is 
not useful. In addition, views provide pre-processing of the 
raw data. 3S 

It will be appreciated that for object-oriented applications 
a uniform table is too flat. In a RDBMS, all objects within 
a table are of the same form, i.e. the objects appear as 
homogeneous rows. As a result, an application that pushes 
various types of objects into the DBMS will need to add 4 q 
more semantics and thus the overhead for storing the object 
as a row is increased. When the object is queried these 
semantics need to be analyzed again by the application in 
order to deduce the type of the object. One approach to 
handling the additional semantics is to store each type of 45 
object in a separate table. Alternatively, the table can be 
enriched with additional typecode columns that need to be' 
analyzed. Either way queries on these objects cannot be 
optimized by the DBMS since the DBMS is not aware of the 
added semantics and the mapping done by the application. 50 
Furthermore, the mapping imposes a higher load of coding 
on the application. The problem of mapping object oriented * 
data into the relational model is often referred to as "imped- 
ance mismatch". 

The SQL standard now provides a facility for creating 55 
typed table hierarchies within the DBMS. The DB2 product 
available from IBM has realized this feature of pushing the 
mapping of different objects into rows of a physical table 
into the DBMS through the use of a so-called hierarchy table 
for a physical representation and through the generation of 60 
so-called logical tables serving as query targets on the table 
hierarchy to project and filter the rows in the hierarchy table 
to match the requested type. The SQL standard also now 
provides for a facility to expand the concept of views over 
tables to typed view hierarchies over typed table hierarchies. 55 

Existing prior systems typically result in large access 
graphs having very poor performance. Essentially every 
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object in the hierarchy is mapped without exploiting the 
meta information of the requested classes and the one stored 
in the structure of the hierarchies. 

Accordingly, there still remains a need for enriching 
tables and views in a relational database management sys- 
tem with the concept of hierarchies and typed rows com- 
prising classes and objects, 

BRIEF SUMMARY OF THIS INVENTION 

The present invention provides a method for defining an 
efficient representation for the complete hierarchy that can 
be shared by multiple references from different classes. 

The method according to the invention features a dense 
implementation which allows subsequent query rewrite to 
eliminate all unneeded access to physical tables. 
Advantageously, this reduces the access to nearly the one 
chosen when not using the view at all. Moreover, this is 
transparent and scaleable. As a cookie, the present invention 
overcomes cheaply the hurdles of insert and updating 
through the hierarchies, which for a straight forward solu- 
tion would be expensive. 

According to the invention, all views in the hierarchy are 
merged into a hierarchy view through the use of case 
expressions for mapping of view types and wrapping of 
overloaded column. Advantageously during this procedure 
the underlying logical tables are eliminated which results in 
a more straight forward query graph. Since the transforma- 
tion is a non-loss transformation and condenses the type 
information within the case-expressions, then update, delete 
and insert operations can be resolved in the graph on a local 
level.. Query rewrite can simplify these case-expressions 
with well known general rules and this minimizes the query 
to the nearly optimal case by eliminating the case- 
expressions and using the resulting predicates to drop non 
accessed table hierarchy from the graph. 

BRIEF SUMMARY OF THE DRAWINGS 

Reference will now be made to the accompanying draw- 
ings which show, by way of example, preferred embodi- 
ments of the present invention and in which: 

FIG. 1(a) shows in diagrammatic form a hierarchy table 
and a hierarchy of logical tables according to a first aspect 
of the present invention; 

FIG. 1(b) shows the hierarchy table of FIG. 1(a) in more 
detail; 

FIG. 2 shows in schematic form an object view hierarchy 
on a single table hierarchy; 

FIG. 3 shows in schematic form an object view hierarchy 
over multiple table hierarchies; 

FIG. 4 shows in flow chart form a method for building a 
type map according to the present invention; 

FIG. 5 shows in flowchart form a method for building a 
case expression in a select list according to another aspect of 
the present invention; 

FIG, 6 shows in flowchart form a method for dispatching 
the user defined typed views to unified groups. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 

The present invention is described in the context of an 
object-relational database management system or 
ORDBMS, such the well-known DB2™ database program 
from IBM. The database management system comprises the 
combination of an appropriate central processing unit (i.e. 
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computer), direct access storage devices (DASD) or disk (User) Create Table Type Hierarchy: 
drives, and the database management software or program. CREATE TYPE person__t AS(name varchar(20), birth- 
It will however be appreciated that the invention is appli- date date) ref using integer; 

cable to other types of relational database management CREATE TYPE emp_t UNDER person_t AS(salary int, 

systems. 5 room char(4)); 

Reference is first made to FIG. 1(a) which shows in CREATE TYPE mgr_t UNDER emp_t AS(dept varchar 
diagrammatic form a mechanism for typed tables in a 

(20), bonus int); 

relational database management system. The typed tables CREATE TYPE student_t UNDER person__t As(major 

indicated generally by reference 10 comprise a hierarchy varchar(20), grade char(l)); 

table 12 and a hierarchy of logical tables 14, indicated 10 ( User ) Create Table Hierarchy: 

individually by 14a, 146, 14c and 14d. The hierarchy table CREATE TABLE person OF person_t(REF IS oid USER 

12 as shown in FIGS. 1(a) and 1(b) comprises a physical GENERATED); 

data table containing all the columns that occur in all typed CREATE TABLE emp OF emp_t UNDER person 

tables as represented by the logical tables 14. INHERIT SELECT PRIVILEGES; 

a u • itto *u u- u ♦ ui ii • i a 15 CREATE TABLE mgr OF mgr_t UNDER emp INHERIT 

As shown in FIG. 1(b), the hierarchy table 12 includes a Qpr Ff ™ ppiviT ppfk; 

typecode column indicated by 16 and object identifier (OID) on^ifn l , L , " TT ^™ 

column indicated by 18, The typecode column 16 is used to ^^J^^^ ° P ^ 

map a row to the proper type (i.e. table). The object identifier /¥ _ IN ™RIT SELECT PRIVILEGES; 

(OID) column 18 identifies the row uniquely within the table m < User ) Create View ^ Hierarch y- 

hierarchy as a distinct object. CREATE TYPE person_vt As(name varchar(20)) ref 

using integer; 

As will now be described, the present invention provides ™ c ATO . ITMPkCD . AC/ 

.. . 4i . ' K . ,. . , ^ j, CREATE TYPE emp vt UNDER person t AS(room 

an internal implementation for a view hierarchy defined by , r ~ r — \ 

a user in an object-relational DBMS or ORDBMS. tvdi: t TIwnrD , AC ,. t 

CREATE TYPE mgr_vt UNDER emp„t AS(dept 

The ORDBMS provides for the creation of typed object 25 varchar(20)); 

views, and these object views can either be root views or CREATE TYPE student_vt UNDER person__t AS(major 

sub-views of other object views. The root view and its varchar(20))* 

sub-views together form an object view hierarchy. A view It wiu ^ app ; eciated lhat the types person_t, emp_J, 
hierarchy on a single table hierarchy is shown in FIG. 2 and mgr _ t and sUldent _t form a type hierarchy for modelling 
described in more detail below A view hierarchy over a the various kinds of people of interest as given by this 
multiple table hierarchy is shown in FIG, 3 and also example. A subtype, e.g. emp_t, inherits all the attributes of 
described in more detail below. ils parent typ6j e g person _ t . h will mrther be apprec iated 
As will be described in more detail below with reference that types must exist before being referred to in a SQL 
to examples, the object view hierarchy comprises the fol- 35 statement. Furthermore, the optional clause "ref using Inte- 
lowing features and attributes. The type used in a given ger" in the statement that creates the root type person_t tells 
object view definition is a structured type, just as in a typed the ORDSMS to use integers as the internal representation 
table definition. The body of an object view definition is a type for references to objects of this type and its subtypes. 
SQL query, as is the case for regular views, but the select list Internally in the ORDBMS, the table hierarchy 100 is 
of the query must be type-compatible with the declared type 40 defined by one physical table 120 or person_hier. The table 
of the object view. As for a typed table, instances of object 120 for person_hier holds all the columns plus the type- 
views have object id's, and the name of the object id column codes 

is specified in the view definition. The object id's are as described in FIG. 1(b). Columns which are non- 

required to be unique within the view's object view existent in a given sub-table are set to NULL in the 

hierarchy, and uniqueness is preferably checked at view 45 person_hier table 120 (as shown in FIG. 1(6)). The 

definition time. Object views may contain references, just as root table 111 and the sub-tables 112, 113, 114 are 

base tables may, and the references must be scoped if they described by logical tables which are represented by 

are to be de-referenced. The scope of a reference in an object views as follows: 

view can be either an object view or a base table. For each Internal (hierarchy table); 

object view in a view hierarchy, the body of the view or - Q CREATE TABLE person_hier (typecode integer, oid 

sub-view specifies how the objects that belong in that integer, name varchar(20), birthday date, salary int, 

specific view or sub-view are to be obtained, i.e. each r00 m char(4), dept varchar(20), bonus int, major 

view/sub-view body tells the ORDBMS how to compute the varchar(20), grade char(l)); 

contents of its particular virtual table within the overall Internal (logical tables): 

hierarchy. 5S CREATE VIEW ONLY(emp)(oid, name, birthdate, 

Reference is made to FIG. 2 which shows an object view salary, room) 

hierarchy over a single table hierarchy 100. In a relational AS SELECT emp__t(oid), name, birthdate, salary, room 

database management system, views are virtual tables FROM person_hier 

whose contents are defined by a query. To a user's applica- WHERE typecode IN (emp_Jcode); 

tion or query, a view looks just like a table. The object view 60 CREATE VIEW (emp)(oid, name, birthdate, salary, 

hierarchy is indicated generally by 102 and defined on a room) 

single table hierarchy 110 comprising a root table for AS SELECT person_t(oid), name, birthdate, salary, 

persons 111, a sub-table for employees 112, a sub-table for room FROM person_hier 

managers 113 and a sub-table for students 114. The single WHERE typecode IN (emp_tcode, mgr_tcode, 

table hierarchy 100 is defined by a user utilizing data 65 student_tcode); 

definition language (DDL) statements in SQL for the When a typed table of the table hierarchy is referenced in 

ORDBMS having the following form; a DMI statement (e.g. a select query), the system generates 



07/15/2003, EAST Version: 1.04.0000 



US 6,421,658 Bl 

5 6 

a fitting query target, i.e. logical table, that will fit the a hierarchy table. Advantageously, this implementation 

queried typed table as illustrated by the following examples: allows most of the DB2™ query compiler code that deals 

SELECT*FROM ONLY(EMP), with query and update operations on table hierarchies, 

CREATE VIEW emponly_qtarget(oid, . . . ); translating them into corresponding H-table queries and 

SELECT*FROM EMP* 5 u P^ ates mterna Uy, to be reused for operations on object view 

™^ , „™,, , . , . hierarchies according to the present invention. For example, 

CREATE VIEW emp_qtarget(oid ); _ wheo a user operates on a table in the person_v hierarchy 

To build the object view hierarchy 102, the ORDEMSi is m (FIG 2) ^ 0RD SMS (e.g. DB2™) is configured to 

provided with a create view DDL statement in SQL. The mtemall the usef , s ^to tions on 

user specifies the object view hierarchy 102 as follows: 1Q t views that are based on the hierarchy ' s H -view 

(User) Create View Hierarchy: Jhe generation of these internal ^ m DB2 t„ according 

CREATE VIEW person_v OF person_vt(REP IS oid t0 the mvention is now described in greater detail. 

USER GENERATED) According to this aspect of the invention, all object views 

• AS SELECT person_vt(int(oid)), name FROM ONLY in tne hierarchy are merged into one view using case 

(person); a5 eX p ress i ons f or mapping and wrapping of overloaded col- 

CREATE VIEW emp_v OF emp_yt UNDER person_v umns . For the object view hierarchy 102 of FIG. 2, the case 

INHERIT SELECT PRIVILEGES expression for the typecode mapping is as follows: 

AS SELECT emp_vt(int(oid)), name, room FROM MAP(person__hier.typecode): 

ONLY(emp); SELECT CASE WREN typecode IN (person_tcode) 

CREATE VIEW mgr_v OF mgr_vt UNDER emp_v 20 AND person where 

INHERIT SELECT PRIVILEGES THEN personL_vcode 

^^ifoM^S name * room, dept WHEN typecode IN (emp_tcode) AND emp_where 



CREATE VIEW student__v OF student_vt UNDER 



THEN emp_vcode 
WHEN typecode IN (mgr_code) AND mgr_where 



person_v 25 thpm ™i 

INHERIT SELECT PRIVILEGES 1 Ht,IN m g r - vcoae 

AS SELECT student_vt(int oid)) name, major FROM WHEN typecode IN(student_tcode) AND exec_where 

ONLY(student); ™ EN studejt^vcode END 
For the object view hierarchy 102, the first statement. AS tv P ecode 

creates an object view 121 person_v of type person_jvt with 30 FROM VALUES(l); 

an object id column named oid. The body of the view tells CREATE VIEW person_v hier (typecode, oid, name, 

the ORDBMS how to derive the extent of the view room, dept, major) 

(including the object id values for the view objects). In this As SELECT map. typecode, oid-expr, 

case, the SQL query that forms the body selects the oid and CASE WHEN map. typecode IN (vc 1} . . . , vc„) 

name columns from the person base table. The next three 35 THEN name-exp^ 

statements create the person_v view hierarchy. The second WHEN map. typecode IN (vc n+1 , . . . , vc m ) 

create view statement shown above creates an object view THEN name-expr 2 END, 

emp__v (shown as 122 in FIG. 2), of type emp_vt, In the ... 

body of the statement, the use of the ONLY keyword in the FROM person__hier, map(person„hier.typecode); 

FROM clause (which can be used in most any SQL query in 40 The view person_vhier contains a Case expression that is a 

the DB2™ database program) instructs the ORDBMS to wrapper in the select- list, i.e. namely the one for the name- 

exclude sub-table rows from consideration. It is essentially column. The MALP query is the case expression which 

a convenient shorthand for the equivalent type predicate and describes the type mapping, 

the object view emp_v will contain rows that are derived It will be appreciated that the above representation for the 

exactly from the emp_table. Similarly, the third create view 45 view hierarchy provides the following advantages: (1) the 

statement creates an object view mgr_v(shown as 123 in representation of the view hierarchy is compact — the 

FIG. 2), and the fourth create view statement creates an amount of Computations necessary for the view encapsula- 

object view student_v (shown as 124 in FIG. 2). tion is limited to the dispatch and mapping of typecodes and 

For the DB2™ database program, in particular, the object expressions. The latter of which can actually be removed by 

ids in the object views are unique within their view hierar- 50 query rewrite in the common simple case. (2) the represen- 

chy. In the case of the person_v hierarchy, this means that tation of the view hierarchy is free of the UNION ALL SQL 

the database program checks (i) that the derivation of the oid statements, which means each row only has to be touched 

column of emp_v is duplicate free, (ii) that the derivation of once. This makes access more efficient. (3) the representa- 

the oid column of mgr_v is duplicate free, (iii) that the tion allows data updates and inserts to be performed through 

derivation of the oid column of student___v is duplicate free, 55 analysis of case expressions only. 

and (iv) that oid's are still unique across these views when The representation of the view hierarchy according to the 
considered together. In the context of the present invention, invention also accommodates existing relational, i.e. non- 
it is assumed that OID uniqueness is given. object, tables. Advantageously, this provides a migration 

Once defined by the user, object views can be used in path for users who have legacy relational data (i.e. existing 
queries, including path queries. The object views can also be 60 data which non-object oriented), and wish to begin exploit- 
updated if the defining SELECT statements are of an updat- ing object-relational modelling for developing new applica- 
able nature. tions. For example, an existing university database includes 

Internally in the ORDBMS, the rows of all views/sub- a pair of relational tables, emp„t and dept_t. The structure 

views in a given object view hierarchy reside together in a of the emp_t table is (eno, name, salary, deptno) and the 

single implementation view that is referred to as a hierarchy 65 structure of the dept_t table is (dno, name, mgrno), where 

view or H-view. Although the H-view is not materialized as the columns cno and dno arc integer keys and the columns 

a physical entity, logically the H-view behaves similarly to "mgrno" and "deptno" are corresponding foreign keys. The 
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object views for the stored data in the legacy database is 
created using the following DDL SQL statements: 

CREATE VIEW dept_v of dept_vt(REF IS oid USER 
GENERATED) 

AS SELECT salary, name, emp_vt(mgmo) 5 
FROM dept; 

CREATE VIEW person_v of person_vt(REF IS oid 
USER GENERATED) 
AS SELECT person_vt(eno), name 
FROM emp 
WHERE salary is null; 
CREATE VIEW emp_v of emp_vt UNDER person_v 
INHERIT SELECT PRIVILEGES 
AS SELECT emp_vt(eno), name, salary 
FROM emp 
WHERE salary <100000; 
ALTER VIEW dept_v ALTER COLUMN mgr ADD 
SCOPE emp_v; 
In the above object view hierarchy for person__v, rows in the 20 
emp_v table with null salary values represent regular 
people, while rows with non-null salaries under $100,000 
represent the employees that are to be made visible through 
the definition for the view emp_v. It will be appreciated that 
the object id's for the object views are derived from the 25 
primary keys of the legacy tables. Once the DDL statements . 
are executed, the resulting dept__v and person„v view 
hierarchies will have the same behaviour in subsequent 
queries as the object views described above. 

When a user operates on a table in the person_v 30 
hierarchy, ORDBMS (e.g. DB2™) internally translates the 
user's query into operations on temporary views for the view 
hierarchy, and having the following form. (These operations 
are based on the hierarchy's H-view.) 

Map (emp.salary) 35 
(Internal) CREATE VIEW emp_with_type_ids(type_ 
id, eno, name, salary) 

SELECT CASE WHEN salary IS NULL THEN 3100 

WHEN salary 100000 THEN 3200 
END as type_Jd, 40 
(Internal) CREATE VIEW personv_hview(type_Jd, oid, 
name, salary) 

AS SELECT type_id, eno, 

CASE WHEN type_id IN (3100, 3200) THEN name 

ELSE NULL END, 45 
CASE WHEN type„id IN (3200) THEN salary 
ELSE NULL END 
FROM cmp,map(emp.salary) WHERE type_id IS 
NOT FULL 

The first view is the view emp_with_type_ids, which 50 
pre-pends one extra column, type_id, to rows of the legacy 
table (emp) upon which the user's view hierarchy was 
defined above. The purpose of the type__id column is to 
distinguish among legacy emp rows based on whether they 
should appear in the view person_v, the view emp_v or 55 
neither. This is done by attaching a type_id to each row 
which identifies its corresponding structured type (i.e. based 
on the user's view definitions) within the object view 
hierarchy. The case expression in the body of the emp_ 
with_type_ids returns the value 3100 when the employee's 60 
salary is null, thereby classifying an emp row as belonging 
to the object view of type person_vt (i.e. person__v) if it 
satisfies the predicate provided in the user's view definition 
for the view person_v . Similarly, the second branch of the 
case expression is based on the predicate of the view 65 
emp_v, associating emp__vt's type id (3200) with those 
rows in emp_that satisfy the cmp_v predicate. If neither 



branch of the case expression is satisfied, then the resulting 
type id will be null. This is appropriate as rows that satisfy 
neither predicate should appear in neither of the hierarchy's 
object views and a null type id will disqualify such rows 
from both. 

The second internal view person_hview as shown above 
is the hierarchy view or H-view. The purpose of this view is 
to provide the view-equivalent of an H-table. As such, the 
person_v: hview has the union of the columns required to 
represent a row for any view/sub-view in the hierarchy. 
Root-level columns of person_hview can be selected 
directly from the view emp_with type ids, while sub- 
view columns (in this case the dept column for the sub-view 
emp_v) must be NULL for the rows that are not part of their 
sub-view of the hierarchy. In general, a column introduced 
by a sub-view must be NULL in all rows pertaining to 
superviews. Since a sub- view may have "sibling" views, it 
is necessary to make sure that the column is NULL in all 
views except those in the sub-hierarchy rooted at the sub- 
view that introduced the column in question. As shown 
above, the body of the view person_hview includes a case 
expression that computes its dept column. It will be appre- 
ciated that the case expression not only discriminates 
between NULL and non-:NULL cases, but also among the 
different expressions that apply for computing the column 
value for a given row. 

In addition to the hidden temporary views, the ORDBMS 
generates an internal realization of possible object view 
query targets having the following form: 

INTERNAL VIEW vperson_qtarget (oid, name) 
(REF IS oid USER GENERATED) 
AS SELECT person_vt(eno), name 
FROM personv_hview 
WHERE type_id IN (3100, 3200); 

INTERNAL VIEW vemp_qtarget OF emp„vt UNDER 
person v 

(dept WITH OPTIONS SCOPE dept_v) 

AS SELECT emp_vt(eno), name, dept 
FROM personv_hview 
WHERE type_id IN (3200); 
The headers, i.e. "Interfaces", of these internal views are 
identical to those of the user's view definitions, but the 
bodies have been reformulated in terms of the hierarchy 
view. The changes to the view body are that (i) the columns 
are taken verbatim from the H-view (except for oid caste), 
and (ii) filtering of rows is now done via the computed type 
id,s rather than via the user's original predicates since the 
type id's themselves were computed based on the user's 
predicates. It is to be appreciated that while the above 
described object view hierarchy is described for a legacy 
database, the implementation details are the same for object 
views on object tables or for object views upon object views 
upon object views. 

Reference is next made to FIG. 3 which shows an object 
view hierarchy over multiple table hierarchies 200. The 
object view hierarchy is indicated generally by 202 and is 
defined on four table hierarchies 210, 220, 230 and 240. The 
first table hierarchy 210 comprises a root table for persons 
211, a sub-table for employees 212, a sub-table for managers 
213 and a sub-table for students 214. The second table 
hierarchy 220 comprises a root table for other employees 
221 and a sub-table for managers 222. The third table 
hierarchy 230 comprises a single root table for managers 
231, and the fourth table hierarchy 240 comprises a single 
root table 241 for students. The table hierarchies 210, 220, 
230 and 240 are defined by a user utilizing data definition 
language (DDL) statements as follows; 
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(User) Create Table Hierarchy A (Covers the whole previous 
hierarchy): 

CREATE TABLE person_a OF person_t (REF IS oid 

USER GENERATED); 
CREATE TABLE emp_a OF emp_t UNDER person_a 5 

INHERIT SELECT PRIVILEGES; 
CREATE TABLE mgr_a OF mgr_t UNDER emp_a 

INHERIT SELECT PRIVILEGES; 
CREATE TABLE student_a OF student_t UNDER 

person_a INHERIT SELECT PRIVILEGES; 
(User) Create Table Hierarchy B (Missing the students and 
persons). 

CREATE TABLE emp_b OF emp_t (REF IS oid USER 

GENERATED); 15 
CREATE TABLE mgr_b OF mgr_t UNDER emp_b 
INHERIT SELECT PRIVILEGES; 
(User) Create Table Hierarchy C (only managers): 

CREATE TABLE mgr_c OF mgr_t (REF IS oid USER 
GENERATED); 20 
(User) Create Table Hierarchy D (only students): 

CREATE TABLE student_d OF student__t (REF IS oid 

USER GENERATED); 
This example shows how each of the user defined sub- 
views can be merged into a single hierarchy view consisting 25 
of as many UNION ALL branches as there are physical 
hierarchy tables. The merging is performed by type mapping 
using case expressions. 

Internally in the ORDBMS, the table hierarchies 200 are 
defined by four physical tables 250, 251, 252 and 253. The 30 
first physical table 250 or PersonA_hier is for persons. The 
second physical table 251 or EmpB_hier is for employees. 
The third physical table 252 or MgrC„hier is for managers 
and the fourth physical table 253 or StudentD_hier is for 
students. 35 

Next the object view hierarchy 202 matching the objects 
from the different branches is built using the "create views" 
statement (as described above) and shown below: 
(User) Create view Hierarchy: 

CREATE VIEW person_v OF person_vt(REF IS oid 40 

USER GENERATED 
UNCHECKED) 
AS (SELECT person_vt(integer(oid)), name FROM 
ONLY(person__a); 45 
CREATE VIEW emp_v OF emp_vt UNDER person_v 
INHERIT SELECT PRIVILEGES 
AS (SELECT emp_vt(integer(oid)), name, room 

FROM ONLY(emp_a)) 
UNION ALL 50 
(SELECT cmp_vt(integcr(oid)), name, room FROM 
ONLY(emp_b)); 
CREATE VIEW mgr_v OF mgr_vt UNDER emp_v 
INHERIT SELECT PRIVILEGES 
AS (SELECT mgr__vt(integer(oid)), name, room, dept 55 
FROM ONLY(mgr_a) 
UNION ALL 

(SELECT mgr_vt(ioteger(oid)), name, room, dept 

FROM ONLY(mgr_b)) 
UNION ALL 60 
(SELECT mgr_vt(integer(oid)), name, room, dept 

FROM ONLY(mgr_c)); 
CREATE VIEW student_v OF student_vt UNDER 
person_v 

INHERIT SELECT PRIVILEGES 65 
AS (SELECT student__vt(initeger(oid)), name, major 
FROM ONLY(student_a)) 



UNION ALL 
(SELECT student_vt(integer(oid)), name, major 
FROM ONLY(student_d)); 
Next as described above, the object views are merged into 
one view hierarchy using case expressions for the typecode 
mapping as follows: 
CREATE VIEW person_vhier (typecode, oid, name, 
room, dept, major) AS 

(SELECT CASE WHEN typecode IN (person_tcode) 
THEN person__vcode 

WHEN typecode IN (emp_tcode) THEN emp_ 
vcode 

WHEN typecode IN (mgr_tcode) THEN mgr_ 
vcode 

WHEN typecode IN (student_tcode) THEN 
student__vcode 
END 

AS typecode, oid, name, room, dept, major 
FROM person_a_hier 
UNION ALL 

(SELECT CASE WHEN typecode IN (emp_tcode) 
THEN emp__vcode 

WHEN typecode IN (mgr„tcode) THEN mgr_ 
vcode END 
AS typecode, oid, name, room, dept, NULL 
. FROM emp_b_hier) 
UNION ALL 

(SELECT CASE WHEN typecode IN (mgr„tcode) 
THEN mgr_vcode END 
AS typecode, oid, name, room, dept, NULL 
FROM mgr_c_hier) 
UNION ALL 

(SELECT CASE WHEN typecode IN (student_tcode) 

THEN student__vcode 
END 

AS typecode, oid, name, NULL, NULL, major 
FROM student_d_hier); 
The illustrated technique of pushing down the type-mapping 
into correlated sub-queries and the wrapping of the expres- 
sions in the select lists allows for overloading of the expres- 
sions in the view definitions. Inserts are possible if the 
definition of the sub-view body does not contain a UNION 
ALL operator. In the above example, this is the case only for 
the view person_v. The person_vcode occurs only in one 
case-expression and therefore is the only possible target of 

an insert into the view person v . Similarly all possible 

targets for an update may be found. Since updates on the 
view emp_v can result in updates on emp_v and mgr_v 
(i.e. all of emp_v*s sub -views), targets are all branches of 
the union containing emp_vcode or mgr_vcode. This infor- 
mation may also be used to find applicable check-constraints 
for insert and update and which triggers will need to be fired 
on the UDI query. In addition, the case-expressions together 
with the where-predicates of the logical view ranging over 
the hierarchy view person_vhier enhance "query rewrite" 
operations as will be described in more detail below. 

The following more general examples are now considered 
with reference to FIGS. 4 to 6. 

For an object view hierarchy over a single table hierarchy, 
the user defines a table type hierarchy which takes the 
following general form: 

CREATE TYPE ttypel AS (ell INT, cl2 INT) REF 
USING INT; 

CREATE TYPE ttype2 UNDER ttypel AS (c21 INT, c22 
INT); 

CREATE TYPE ttype3 UNDER ttype2 AS (c31 INT, 
c32); 
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CREATE TYPE ttype4 UNDER ttypel AS (c41 INT, 
c42); 

Next the user defines a table hierarchy as follows; 

CREATE TABLE tl OF ttypel (REF IS oid USER 

GENERATED); 5 
CREATE TABLE t2 OF ttype2 UNDER tl INHERIT 

SELECT PRIVILEGES; 
CREATE TABLE t3 OF ttype3 UNDER t2 INHERIT 

SELECT PRIVILEGES; 
CREATE TABLE t4 OF ttype4 UNDER tl INHERIT 

SELECT PRIVILEGES; 
Internally, the hierarchy table, tl_hier, is created in the 
ORDBMS as follows: 

CREATE TABLE tl_hier (ttc INT, oid INT ell INT, cl2 15 

INT, c21 INT, c22 INT, c31 INT, c33 INT, c41 INT, c42 

INT); 

Next, the logical tables are created internally in the 
ORDBMS as follows; 

CREATE VIEW "tlonly_qtarget" 20 
AS SELECT ttypel(oid), ell, cl2 FROM tl2_hier 
WHERE ttc IN (<ttcl>); 
CREATE VIEW "t2only_qtarget" 
AS SELECT ttype2(oid), ell, cl2, c21, c22 
WHERE ttc IN (<ttcl>); 
CREATE VIEW "t3only__qtarget" 
As SELECT ttype3(oid), ell, cl2, c22, c31, c32 

FROM tl_hier 
WHERE ttc IN (<ttc3>); 
CREATE VIEW "t4only_qtarget, 
AS SELECT ttype4(oid), ell, cl2, c41, C42 
FROM tl_hier 
WHERE ttc IN (<ttc4>); 
For a single table hierarchy, the user creates a view 35 
hierarchy having the following form: 

CREATE TYPE vtypel AS (vcl INT) REF USING INT; 
CREATE TYPE vtype2 UNDER vtypel AS (vc2 INT); 
CREATE TYPE vtype3 UNDER vtype2 As (vc3 INT); 
CREATE TYPE vtype4 UNDER vtypel AS (vc4 INI); 40 
CREATE VIEW vl OF vtypel (REF IS oid USER 
GENERATED) 

AS SELECT vtypel (INT(oid)), ell 

FROM ONLY (tl) 
WHERE (cl2>cll) 
CREATE VIEW v2 OF vtype2 UNDER vl INHERIT 
SELECT PRIVILEGES 
AS SELECT vtype2 (INT(oid)), ell, c21 

FROM ONLY (t2) 
WHERE (cl2>c22), 
CREATE VIEW v3 OF vtype3 UNDER v3 INHERIT 
SELECT PRIVILEGES 
AS SELECT vtype3 (INT(oid)), ell, c21, c31 

FROM ONLY (t3) 55 
WHERE (cl2>c31): 
CREATE VIEW v4 OF vtype4 UNDER vl INHERIT 
SELECT PRIVILEGES 
AS SELECT. vtype4 (INT(oid)), ell, c41 

FROM ONLY (t4) 60 
WHERE (c42=5); 
In the ORDBMS, the hierarchy view is merged using 
CASE expressions for mapping of types with WHERE 
causes in views as follows: 

CREATE VIEW vl_hier 65 
AS SELECT vtc, oid, cl as vcl, c21 as vc2, c31 as vc3, 
c41 as vc4 



45 



50 



FROM tl_hier, 
(SELECT CASE WHEN tl_hier.ttc IN (<ttcl>) 
AND (C12>C11) THEN <vtcl> 
WHEN tl_hier.ttc IN (<ttc2>) . 
. AND (cl2>c22) THEN <vtc2> 
WHEN tl_hier.ttc IN (<ttc3>) 
AND (c21>C31) THEN <vtc3> 
WHEN tl_hier.ttc IN (<ttc4>) 
AND (c42 =5) THEN <vtc4> 
ELSE NULL END FROM VALUES(l)) 
AS typemap (vtc) 
WHERE vtc IS NOT NULL; 
The logical views are generated internally in the 
ORDBMS as follows: 
CREATE VIEW "only(vl)" 
As SELECT vtypel(oid), vcl FROM vl hier 
WHERE vtc IN (<vtcl>); 
CREATE VIEW "only(v2)" 
AS SELECT vtype2(oid), vcl, vc2 

FROMvl_hier 
WHERE vtc IN (<vtcl>); 
CREATE VIEW "only(v3)" 

AS SELECT vtype3(oid), vcl, vc2,- vc3 

FROM vl_hier 
WHERE vte IN (<vtc3>); 
CREATE VIEW «only(v4)" 

AS SELECT vtype4(oid), vcl, vc4* 

FROM vl_hier 
WHERE vtc IN (<vtc4>); 
Reference is also made to FIG. 4 which shows in flow- 
chart form a method for building a type map or "typemap" 
according to the present invention denoted generally by 
reference 300. 

As shown in FIG. 4, the first step indicated by block 301 
comprises getting the first view in the hierarchy and gener- 
ating an empty case "CASE ELSE NULL END". The next 
step in building the type map in block 302 comprises the 
following operations. Getting the table specified in the view 
body's FROM statement. This table is a logical table and has 
an IN predicate which describes its type, for example, 

ONLY(empt)<==>type IN (<emp_type>) 

empt<=> 

type IN (<emp_type<, <mgr_type>) 
The next operations in block 302 involve getting the type- 
code of the view and also the IN-predicate which describes 
the view (i.e. same principle as for a logical table). The next 
step in block 303 involves mapping the table type to the 
view type and comprises adding a new WHEN to the case 
expression: 

tlonly_qtarget<==>ttc IN (<ttcl>) 

tl_qtarget<==>ttc IN (<ttcl>, <ttc2>, <ttc3>, <ttc4) 

and THEN 

WHEN ttc IN (<ttc>) AND (cl2>cll) THEN <vtcl> 
If there are other views, these steps are repeated (blocks 304 
and 305), otherwise the type map is complete. 

Next the merging of an object view hierarchy over a 
single table hierarchy using column overloading is 
described. The user creates a view type hierarchy having the 
following form: 

CREATE TYPE vtypel AS (vcl INT) REF USING INT; 

CREATE TYPE vtype2 UNDER vtypel AS (vc2 INT); 

CREATE TYPE vtype3 UNDER vtypc2 AS (vc3 INT); 

CREATE TYPE vtype4 UNDER vtypel AS (vc4 INT); 

CREATE VIEW vl OF vtypel (REF IS oid USER 
GENERATED) 
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AS SELECT vtypel(INT(oid)), ell 
FROM ONLY(tl) 
CREATE VIEW v2 OF vtype2 UNDER vl INHERIT 
SELECT PRIVILEGES 

AS SELECT vtype2(INT(oid)), cll+cl2, c21 5 
FROM ONLY(t2); 
CREATE VIEW v3 OF vtype3 UNDER v3 INHERIT 
SELECT PRIVILEGES 

AS SELECT vtype3(INT(oid)), ell, c21 +c31, 
c31-c32 

FROM ONLY(t3); 
CREATE VIEW v4 OF vtype4 UNDER vl INHERIT 
SELECT PRIVILEGES 
AS SELECT vtype4(INT(oid)), cll*c42, c41 

FROM ONLY(t4); 1$ 
Internally, the ORDBMS creates the following hierarchy 
view: 

CREATE VIEW vl_hier 
AS SELECT vtc, oid, 

CASE WHEN vtc IN (<vtcl>, <vtc3>) THEN ell 

WHEN vtc IN (<vtc2>) THEN cll+cl2 

WHEN vtc IN (<vtc4>) then cll+c42 

ELSE NULL END AS vcl, 
CASE WHEN vtc IN (<vtc2>) THEN c21 

WHEN vtc IN (<vtc3>) then c21+c31 

ELSE NULL END AS vc2, 
CASE WHEN vtc IN (<vtc3>) THEN c31-c32 

ELSE NML END AS vc3, 
CASE WHEN vtc IN (<vtc4>) THEN c41 

ELSE NULL END AS vc4, 
FROM tl_hier, (SELECT CASE . . . ) AS typemap 
(vtc) 

WHERE vtc IS NOT NULL; 

Reference is now made to FIG. 5 which shows a method 
for building a case expression of column vcy in the select list 35 
of the hierarchy view described above. In FIG. 5, the method 
for building a case expression is denoted generally by 
reference 400. 

As shown in FIG. 5, the first step (block 401) in the 
method for building a case expression 400 comprises gen- 40 
erating an empty case starting with the first view, i.e. the root 
view. The next step in block 402 involves getting the 
expression making up the view-column vcy in the view 
definition at hand. It will be appreciated that not all columns 
in the view hierarchy are in all the views, e.g. an emp will 45 
not have a bonus-column. Next, a check is made in block 
403 to determine if an expression exists for this view, if an 
expression exists for vcy, then in block 404 a search is made 
to find the expression in the WHEN <pred> THEN <expr> 
branches of the case expression. If the expression is found 50 
(block 405), then only the typecode of this view is added to 
the IN-predicate of the found WHEN (block 406). 
Otherwise, there is "column overloading". The expression is 
new and gets its own WHEN branch in the CASE expression 
(block 407). These steps are repeated for all the views 55 
(blocks 408 and 409). 

As described above, the present invention is also appli- 
cable to multiple underlying table hierarchies, as will now be 
generalized with reference to the following example and 
FIG. 6. The user creates the following table type and table 60 
hierarchies: 

CREATE TYPE ttypel AS (ell INT, cl2 INT) REF 
USING INT; 

CREATE TYPE ttype2 UNDER ttypel AS (c21 INT, c22 
INT); 65 

CREATE TYPE ttype3 UNDER ttype2 AS (c31 INT, 
c32); 



CREATE TYPE ttype4 UNDER ttypel AS (c41 INT, 
c42); 

CREATE TABLE tla OF ttypel (REF IS oid USER 

GENERATED); 
CREATE TABLE t2a OF ttype2 UNDER tla INHERIT 

SELECT PRIVILEGES; 
CREATE TABLE t4a OF ttype4 UNDER tla INHERIT 

SELECT PRIVILEGES; 
CREATE TABLE t2b OF ttype2 (REF IS oid USER 

GENERATED); 
CREATE TABLE t3b OF ttype3 UNDER t2b INHERIT 

SELECT PRIVILEGES; 
Internally, the following hierarchy table is created by the 
ORDBMS: 

CREATE TABLE tla__hier (ttc INT, oid INT ell INT, 

cl2 INT, c21 INT, c22 INT, c41 INT, C42 INT); 
CREATE TABLE t2b_hier (ttc INT, oid INT ell INT, 

cl2 INT, c21 INT, c22 INT, c31 INT, C33 INT); 
Internally, the following logical tables are also created; 
CREATE VIEW "tla_qtarget" 

AS SELECT ttypel(oid), ell, cl2 FROM tla_hier 
WHERE ttc IN (<ttcl>); 
CREATE VIEW "onlyt2a_qtarget" 

AS SELECT ttype2(oid), ell, cl2, c21, c22 

FROM tla_hier 
WHERE ttc IN (<ttcl>); 
CREATE VIEW "t4a_qtarget M 
AS SELECT ttype4(oid), ell, cl2, c41, c42 

FROM tla_hier 
WHERE ttc IN (<ttc4>); 
CREATE VIEW "t2b_qtarget" 
AS SELECT ttype2(oid), ell, cl2, c21, c22 

FROM tlb_hier 
WHERE ttc IN (<ttcl>); 
CREATE VIEW "t3b_qtarget" 
AS SELECT ttype3(oid), ell, cl2, c21, c22, c31, c32 

FROM tlb_Jiier 
WHERE ttc IN (<ttc3>);: 
For an object view hierarchy spanning both table 
hierarchies, the user creates a view hierarchy having the 
following form: 
CREATE TYPE vtypel AS (vcl INT) REF USING INT; 
CREATE TYPE vtype2 UNDER vtypel AS (vc2 INT); 
CREATE TYPE vtype3 UNDER vtype2 AS (vc3 INT); 
CREATE TYPE vtype4 UNDER vtypel AS (vc4 INT); 
CREATE VIEW vl OF vtypel (REP IS oid USER 
GENERATED) 

AS SELECT vtypel(INT(oid)), ell 

FROM ONLY (tla) 
WHERE (cl2>cll), 
CREATE VIEW v2 OF vtype2 UNDER vl INHERIT 
SELECT PRIVILEGES 
AS (SELECT vtypc2(INT(oid)), ell, c21 

FROM ONLY(t2a)) 
UNION ALL 

(SELECT vtype2(INT(oid)), ell, c21 
FROM ONLY(t2b)); 
CREATE VIEW v3 OF vtype3 UNDER v3 INHERIT 
SELECT PRIVILEGES 
AS SELECT vtype3(INT(oid)), ell, c21, c31 
FROM ONLY (t3b); 
CREATE VIEW v4 OF vtype4 UNDER vl INHERIT 
SELECT PRIVILEGES 
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AS SELECT vtype4(INT(oid)), ell, c41 
FROM ONLY (t4a); 
Internally, the following hierarchy view is created: 
CREATE VIEW vl_hier 
AS (SELECT vtc, oid, ell as vcl, c21 as vc2, 

NULL as vc3, c41 as vc4 
FROM tla_hier, 
(SELECT CASE WHEN tla_hier.ttc IN (<ttcl>) 
WHEN tla„hier.ttc IN (<ttc2>) 
THEN <vtc2>) 

WHEN tla_hier.ttc IN (<ttc4>) 
THEN (<vtc4>) 

ELSE NULL END FROM VALUES(l)) 
AS typemap (vtc) 
WHERE vtc IS NOT NULL) 
UNION ALL 

(SELECT vtc, oid, ell as vcl, c21 as vc2, 

c31 as vc3, NULL as vc4 
FROM t2b__hier, 

(SELECT CASE WHEN t2b_hier.ttc IN (<ttc2>) 
THEN <vtc2> 

WHEN t2b_hier.ttc IN (<ttc3>) 
THEN <vtc3>) 

ELSE NULL END FROM VALUES(l)) 
AS typemap (vtc) 
WHERE vtc IS NOT NULL); 

Internally, the following logical views are also created; 
CREATE VIEW "only (vl)" 
AS SELECT vtype oid), vcl FROM vl_hier 
WHERE vtc IN (<vtcl>); 
CREATE VIEW "only(v2)" 
AS SELECT vtype2(oid), vcl, vc2 
FROM vl__hier 
WHERE vtc IN (<vtcl>); 
CREATE VIEW "only(v3)" 
AS SELECT vtype3(oid), vcl, vc2, vc3 
FROM vl_hier 
WHERE vtc IN (<vtc3>); 
CREATE VIEW "only(v4)" 
AS SELECT vtype4(oid), vcl, vc4 

FROM vl_hier 
WHERE vtc IN (<vtc4>); 
Reference is made to FIG. 6 which shows in flowchart 
form a method for dispatching the views over hierarchy 
branches according to this aspect of the present invention. 

As shown in FIG. 6, the first step indicated by block 501 
comprises getting the first SELECT branch of the UNION 
ALL in the body of the current view. The next step indicated 
by block 502 involves the following operations: finding first 
the logical table in the FROM clause of the SELECT-branch; 
then getting the hierarchy table that the logical table belongs 
to; and getting the branch in the expanded hierarchy view 
that ranges over the hierarchy table. The next step in block 
503 involves determining if a branch in the hierarchy view 
exists. If a branch does not exist, then a new branch is 
created in the hierarchy view with the hierarchy table in the 
FROM and an empty type-mapping as shown in block 504. 
Next in block 505, the new branch is added to the UNION 
ALL of the hierarchy view. If a branch in the hierarchy view 
exists (block 503), then the steps in blocks 504 and 505 are 
bypassed. Next in block 506, the SELECT in the view body 
is merged into the found or created branch in the hierarchy 
view. The next step in block 507 involves getting the next 
SELECT branch in the body of the current view If another 
SELECT branch exists (block 508), then the above merging 
steps are repeated, otherwise the merging is complete. 
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In the operation of the ORDBMS, the query rewrite phase 
can simplify the query graph by determining branches which 
do not contain information for the query and also allows the 
exploitation of indexes in the underlying hierarchy table. 

5 This reduces locking and increases query perform ance in the 
ORDRMS. The query rewrite simplifies the case- 
expressions by applying known general rules which mini- 
mize the query graph to the nearly optimal case by elimi- 
nating the case-expressions and using the resulting 

10 predicates to drop the non-accessed table hierarchy from the 
graph. 

The multi-table hierarchy example from above is used to 
illustrate the query rewrite phase. 

CREATE VIEW person„v OF person_vt (REP IS oid 
15 USER GENERATED) 

AS SELECT person__v(integer(oid), name FROM 
ONLY(person_a); 
CREATE VIEW emp_v OF emp_vt UNDER person_v 
INHERIT SELECT PRIVILEGES 
20 AS (SELECT emp_v(integer(oid), name, room FROM 
ONLY(emp_a)) 
UNION ALL 

(SELECT emp_v(integer(oid), name, room FROM 
ONLY(emp_J>)) 
25 'The user invokes the following query: 

SELECT oid, name FROM only(person_v) WHERE 
name~' Smith'; 

According to the present invention, the full expanded query 
including the hierarchy view is as follows (for clarity only 
the used columns are shown): 
SELECT oid FROM person„v„only_qtarget WHERE 

name«* Smith"; 
person_v_only„qtarget: 
35 SELECT person_vt(oid), name FROM person_vhier 
WHERE vtc IN (<person_vtc>); 
person_vhier; 
(SELECT map_a.vtc, oid, 

CASE WHEN map_a.vtc IN (<person_vtc>, <emp_ 
40 vto) 

THEN name ELSE NULL END, 
FROM person_a_hier, mappa(person_a_ 
hier.typecode)) 
45 UNION ALL 

(SELECT map_J>.vtc, oid, 

CASE WHEN map_a.vtc IN (<emp_ytc>) THEN 
name ELSE NULL END, 
FROM emp_b_hier, map_b (emp_b__hier.typecode)); 
50 mappa(person_a_hier.typecode): 

SELECT CASE WHEN typecode IN (<person_ttc>) 
THEN <person_vtc> 

WHEN typecode IN (<emp_ttc) THEN <emp_vtc) 
ELSE NULL END AS vtc FROM VALUES(l); 
55 map_b(emp_b__hier.typecode); 

SELECT CASE WHEN typecode IN (<emp_ttc) THEN 
<emp„_ytc) 

ELSE NULL END AS vtc FROM VALUES(l); 
Step 1: Merge the selects together and push them through the 
UNION ALL operator: 
(SELECT person_vt(oid), 

CASE WHEN map_a.vtc IN (<person_vtc>, <emp_ 
vto) 

65 THEN name ELSE NULL END, 

FROM person_a_hier, mapa(person_a_hier.typecode) 
WHERE map_a.vtc IN (<person_vtc>) AND 
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(CASE WHEN map_a.vtc IN (<person_vtc>, <emp_ it may have on the content of the single branches. For 

vto) example, the definition of range constraints for the oid's in 

THEN name ELSE NULL END=' Smith')) each table hierarchy would cause query rewrite again to drop 

UNION ALL branches that are out of range for the required oid. The 

5 dropping of these branches becomes especially important in 

(SELECT person_vt(oid), aQ env ironment that joins different data sources with either 

CASE WHEN map.__a.vtc IN (<emp__vtc>) THEN lots of interface overhead or a slower connection to a remote 

name ELSE NULL END, data source. Advantageously, the present invention mini- 

FROM emp_b_hier, map_b(emp_b_hier.typecode) mizes the access and provides a complete encapsulation of 

WHERE map_a.vtc IN (<person_vtc>) AND 10 &z underlying relational groundwork. 

(CASE WHEN map_a.vtc IN (<person_vtc>, <emp_ The present invention may be embodied in other specific 

vtc>) ' forms without departing from the spirit or essential charac- 

THEN name ELSE NULL END- 'Smith')); teristics thereof. Therefore, the presently discussed embodi- 

Step 2: Simplify the case wrapper that was pulled into the ments are considered to be illustrative and not restrictive, the 

wbere-clause. The WHERE clause claims that map_a.vtc 15 scope of the invention being indicated by the appended 

must be <person_vtc>. So the case can be dropped and claims rather than the foregoing description, and all changes 

replaced by the qualifying when-branches expression. If which come within the meaning and range of equivalency of 

several when predicates would qualify a list OR'ed predi- tne claims are therefore intended to be embraced therein, 

cates is generated. If none qualify (as in the second branch What is claim is: 

of the example) a FALSE is generated. The case wrappers 2 o 1 - In a relational database management system, a method 

can also be simplified in this example. for creating a hierarchy view on top of a table hierarchy, 

(SELECT person_vt(oid), name, comprising: 

FROM person_a_hier, mapa(person_a_ (a) storing a user definition for a table hierarchy and a 

hier typecode) ta ^ e tv P e hierarchy, wherein the table hierarchy 

WHERE map_a.vtc IN (<person_vtc>) AND name- 25 includes a physical table storing all columns of one or 

* Smith*) more typed tables in the table type hierarchy; and 

UNION ALL (k) generating a hierarchy view from the table hierarchy 

/or , T „„ g ... xrTTTT and table type hierarchy, wherein the hierarchy view 

^5££T P e ™ n - v /(° ld )' m ^ J x comprises a single unified view on the table hierarchy 

mP - b " \^ P ~ (emP " S A l S e . C r°c e i 30 comprised of one or more logical views for each of the 

WHERE map_a.vtc IN (<person_vtc>) AND FALSE; ^ tables in the table type hierarchy. 

StCP V ^I? ? r0VCr . aD ^o°,? P1Dg u f ^ ranc * es - ™ e 2. The method as claimed in claim 1, wherein the hier- 

T W ™ RE , cla f e 15 f^ v E ' ^ th T C r brai ! ch ? f the archy view is shareable by one or more query targets. 

UNION ALL can be dropped. A UNION ALL with only one 3 ^ method asclaimed in claim 2 , wherein said step (b) 

branch is a trivial operation and can be omitted f t - . * • *u i • 

^ wminv^ 35 of generating a hierarchy view comprises merging the logi- 

SELECT person_vt(oid), name, ca i views specified in a view type hierarchy into a case 

FROM person_a_hier, mapa(person_a_ expression for type mapping of rows read from the table 

hicr.typecode) hierarchy. 

WHERE map__a.vtc IN (<person_vtc>) AND name- 4, The method as claimed in claim 3, further including the 

'Smith'; 40 s t e p of using a case expression in a select list to unify 

Step 4: Pull up the correlated subquery expressions in the select list of a logical view in the view 

SELECT person__vt(oid), name, type hierarchy. 

FROM person_a_hier, VALUES(l) 5. The method as claimed in claim 1, wherein more than 

WHERE CASE WHEN typecode IN (<person_ttc>) one table hierarchy is stored, and further including the steps 

THEN <person„vtc> 45 of generating a hierarchy view for each of the table hierar- 

WHEN typecode IN (<emp_ttc) THEN <emp„vtc) chies and grouping the hierarchy views according to the 

A ELSE NULL END IN (<person_vtc>) AND name= underlying table hierarchies. 

'Smith'; 6. The method as claimed in claim 1, wherein logical 

Step 5: Simplify the case expression in the WHERE clauses views are used as query targets for accessing the hierarchy 

The outer IN predicate can only be true if the case expres- 50 view. 

sion resolves to it. Therefore the "typecode IN (<person_ 7. The method as claimed in claim 3, wherein said step of 

tto)" must be true to succeed. So the whole predicate can merging the logical views into a case expression comprises 

be replaced by the when predicate. If multiple possibilities (i) generating an empty case for a first view in the view type 

exist (multiple values in the IN-list), the when-predicates are hierarchy, (ii) determining if an expression exists for col- 

OR'ed. 55 umns in the first view, (iii) if the expression exists, then 

SELECT person_vt(oid) } name, adding a typecode for the first view to a corresponding 

FROM person_a_hier, VALUES(l) branch in the case expression, (iv) if the expression does not 

WHERE typecode IN (<person_ttc>) AND name- exist, then adding a new branch for the columns, and (v) 

'Smith'; repeating steps (ii) to (iv) for other logical views. 

If an index on typecode or: name exists it can be 60 **■ A computer program product for use on a computer 

exploited since it is ranging immediately over the wherein queries are entered for retrieving data from tables 

physical table. Also check-constraints on name stored in memory and wherein means are included for 

can help to validate if 'Smith' can be in the table defining a table hierarchy for retrieving data from the tables, 

at a iL said computer program product comprising: 

If the branches do not drop away as easily as in this 65 a recording medium; 

example, e.g. doing a select on the whole hierarchy for a means recorded on said medium for instructing said 

specific oid, then the ORDBMS can still exploit information computer to perform the steps of, 
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(a) storing a user definition for a table hierarchy and a 
table type hierarchy, wherein the table hierarchy 
includes a physical table storing all columns of one 
or more typed tables in the table type hierarchy; and 

(b) generating a hierarchy view from the table hierar- 
chy and table type hierarchy, wherein the hierarchy 
view comprises a single unified view on the table 
hierarchy comprised of one or more logical views for 
each of the typed tables in the table type hierarchy. 

9. The computer program product as claimed in claim 8, 
wherein the hierarchy view is shareable by one or more 
query targets. 

10. The computer program product as claimed in claim 9, 
wherein said step (b) of generating a hierarchy view com- 
prises merging the logical views specified in a view type 
hierarchy into a case expression for type mapping of rows 
read from the table hierarchy. 

11. The computer program product as claimed in claim 10, 
further including the step of using a case expression in a 
select list to unify expressions in the select list of a logical 
view in the view type hierarchy. 

12. The computer program product as claimed in claim 8, 
wherein more than one table hierarchy is stored, and further 
including the steps of generating a hierarchy view for each 
of the table hierarchies and grouping the hierarchy views 
according to the underlying table hierarchies. 

13. The computer program product as claimed in claim 8, 
wherein logical views are used as query targets for accessing 
the hierarchy view. 

14. The computer program product as claimed in claim 
10, wherein said step of merging the logical views into a 
case expression comprises (i) generating an empty case for 
a first view in the view type hierarchy, (ii) determining if an 
expression exists for columns in the first view, (iii) if the 
expression exists, then adding a type code for the first view 
to a corresponding branch in the case expression, (iv) if the 
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expression does not exist, then adding a new branch for the 
columns, and (v) repeating steps (ii) to (iv) for other logical 
views. 

15. A relational database management system for use with 
5 a computer system wherein queries are entered for retrieving 

data from tables and wherein means are included for defin- 
ing a table hierarchy for retrieving data from the tables, said 
system comprising: 

(a) means for receiving a user definition for a table 
10 hierarchy and a table type hierarchy, wherein the table 

hierarchy includes a physical table storing all columns 
of one or more typed tables in the table type hierarchy; 
and 

(b) means for generating a hierarchy view from the table 
15 hierarchy and the table type hierarchy, wherein the 

hierarchy view comprises a single unified view on the 
table hierarchy comprised of one or more logical views 
for each of the typed tables in table type hierarchy. 

16. The relational database management system as 
20 claimed in claim 15, wherein the hierarchy view is shareable 

by one or more query targets. 

17. The relational database management system as 
claimed in claim 16, wherein said means for generating 
include means for merging the views specified in a view type 

25 hierarchy into a case expression for type mapping of rows 
read from the table hierarchy. 

18. The method as claimed in claim 2, wherein more than 
one table hierarchy is stored, and further including the steps 
of generating a hierarchy view for each of the table hierar- 

30 chies and grouping the hierarchy views according to the 
underlying table hierarchies. 

19. The method as claimed in claim 2, wherein logical 
views are used as query targets for accessing the hierarchy 
view. 

35 
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